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Tnis MTB describes proposed changes to the I/0 Daemon in support 
of the Access [Isolation Mechanism. The reader is assumed to be 
familiar with the basic principtes of the Access Isotation 
Mechanism, as well as the relevant terminologys defined in 
MTB-16D0< . 


The modifications suggested here were, for the most. part, 
originally proposed to satisfy certain requirements of the Air 
Force Data Services Center. However, as with other features of 
the Access Isolation Mechanism, most of the new features proposed 
for tne I/0 Daemon will be of general use at many Multics sites. 
The following four requirements are specifically considerea in 
this MTB . tf 


4) It must be possible to instruct a device driver process’ to 
handle only requests of @ specified range of access ciasses. 


2) The head sheet for each printout must contain a banner 
identifying the access class assigned to fhe printout. | 


3) A user must be able to specify, by means of dprint command 
options or defaults, that header and footer labels be piaced 
on each page of printed output. 


4&) Each printer driver process must be capabie of preparing an 
“accountability form’ for each plece of printed output. (In 
the case of AFDSC, an accountability form wili be used to 
officially record the transmission of a classified printout to 
an appropriately authorized user. At other sites, forms of 
somewhat different format may be used for a similar purpose.) 


Since the use of the above features is at the discretion of the 
individual site or user, no change in I/0 Daemon operation wilt 
result unless desired. ; 


Muitics project internal working documentation. Not to be 
reproduced or distributed outside the Multics project. 
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In the discussion which follows, the implications of each of the 
above four requirements is examined and an Implementation is 
described. Afterwards, some access control problems posed by the 
Access Isoiation WNechanism for tne [/6 Daemon are investigated. 
Finally, a summarization of all proposed changes is presented. 


Access Class Ranges for Dewice Drivers 


It is desired that an access class range be associated with each 
device driver process and that onty requests within this range be 
handied by the driver. In order to understand the meaning and 
implications of this idea, it Is worthwhile to obriefty review 
some features of the I/0 Daemon organization and operation. 


The collection of user requests into queues and the subsequent 
distribution of these requests to driver processes revolves 
around the notion of device classes. When a user submits an I/0 
requesf, he either explicitty specifies a device class or else a 
default device ciass is assumed. The device class uniquely 
determines a set of queues, each of which represents a different 
priority. Such a set of queves wiil be referred to hereafter as 
a “queve group." Each driver process is uniquely associated with 
@ device class and hence with a queue group. Orivers of the same 
device ciass are considered to be equivalent in the sense that 
any one of them can handle any request from the appropriate queue 
groupe Thus, when a driver informs the coordinator that if is 
ready for work, the coordinator simply selects the oldest request 
of highest priority from the queue group associated with the 
 G@river®’s device class. 


With the advent of the Access Isotation Mechanism, each driver 
process will! be assigned a specific authorization. To the 
greatest extent possibie, driver processes will not make use of 
any system privliegese Therefore, if we were to aliow grivers of. 
different authorizations to betong to the same device class, 
these drivers couid no fonger be considered equivalent. A 
segment accessible to one of the drivers might not be accessible 
to another. Hence, in order to preserve the meaning of device 
classes, ali drivers of the same device class wli! have the same 
authorization. Cleariys, this authorizatlon defines an upper 
access timit for the device class. 


A simple way to proceed in achieving the desired access ranges 
for arivers is to associate the access range with the device 
classe Ignoring the detalis of this approach for the moment, 
only one conceptual problem is evident. Where in the current 
system there now exists one device class and one queue group for 
a category of devices, eeges central site printers, there would 
be perhaps several device ciasses and several corresponding queue 
groups in the new scheme, each having a different access range. 
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Such an arrangement is by no means technically infeasibie, but it 
does create Inconveniences for the user and fhe operations staff. 
The user certaliniy does not wish to concern himsetf with which 
access range is appropriate for his requeste This should and 
could be determined automaticaily by the systeme However, a more 
serious problem arises over the fact that the access ranges 
associated with a device class are intended to be dynamically 
reconfigurable. For exampies a site with three printers may 
ordinariiy have three device ciasses with three different access 
ranges for these printers. If one printer should fails however, 
it may be desirabie to reconfigure the access ranges of the 
remaining two printers so as to process the requests formeriy 
handled by the inoperative printer. Unfortunately, there is no 
easy way to accomplish this reconfiguration since the requests 
nave already been segregated Into separate queues basea on the 
original fhree access rangese 


In order to solve the problem described above, if IS proposed 
that the one-to-one mapping between device classes and queue 
groups be changed to a many-fo-one mappinge In other words, it 
witft be possibfe for one queue group to serve many device 
Classese Actually, it is convenient to think of the queue group 
as defining a “static” device ciass which is identical to the 
current notion of device class. When aeouser submits’ an I/0 
request, he will specify (explicitiy or implicitty). the static 
device ciass. ODriver processes wiil be associated with “dynamic” 
device classeS,» many of which can draw requests from the same 
static device class. Thus, whenever it is desired to reconfigure 
the access ranges of tne dynamic device classeS,s no reshuffilng 
of the queues is necessary. . 


Aithough the change described above may sound rather severe, this 
approach has been chosen for the very reason that It requires 
refativety few changes to the I/0 Daemon software. As far as the 
relationshlp between the coordinator and drivers Is concerned, 
the implementation of device classes is basically unchanged. A 
new parameter for the I/0 Daemon parms file will be defined which 
permits specification of the access range of a (dynamic) device 
classe Also» a secona new parameter will be definea which 
permits specification of a queve group name for a device class. 
When the parms file is 6xamined during the initialization of the 
coordinator, all device ciasses sharing the same queue group will 
be threaded together. Furthermore, a new data base, called the 
queue group table, wil! be constructed which contains one entry 
for each queue groupe. Each entry will have a pointer to the head 
of the fhreaded list of associated device classes as well as 
pointers to (or indexes of) the message segments in the queue 
groupe Each device class entry wiil contain a pointer to its 
associated queue group entrye 


Aside from the extra initiaitization described above, only one 
other section of the I/0 Coordinator will require significant 
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modification. (Note that no changes fo the drivers are necessary 
to implement access class ranges.) The subroutine responsible 
for reading requests from the queues, called find _next_request_s>s 
must understand the device class to queue groaun manning. When 
Given a device ciass, find _next_request_ wili ascertain the 
appropriate queue group and read the oldest request from highest 
priority non-empty queue (as it does now). It must then 
determine if the access class of the request message is within 
the access range of the specified device ciass. If Soe the 
request is returned as usuale If nots find next _request_ will 
scan the threaded tist of device ciasses for the queue group 
until tinding a device class with the proper access range. The 
message ID of the request will then be added to a “waiting tist” 
for that device classe The reading of messages, and the adding 
of these messages to waiting tists, wlll continue until a message 
is found within the access range of the specified device ciass or 
untit the queue group is exhaustede Thus, it can now be seen, 
that the aigorithm followed by finarinext_request_ is to first 
check the waiting list for a device class and, if this is empty, 
to then begin reading messages from the associated queues. 


The effect of the above scheme is to delay the binding between a 
request ana a dynamic device class untli the moment the request 
ls read from the queves. Furthermore, this binding can always be 
reconfigured, even for reauests In the waiting tists. This is 
accomplished by Simply changing the parms file and then 
reinitializing the coordinator. The old waiting tists are 
discarded and new ones are created for the new dynamic device 
classes. No jJuggiing of the queves Is ever necessary. Note also 
that at instattatlons which continue to maintain a one-to-one 
correspondence between queue groups and dynamic device classes, 
no requests will ever be added to a waiting tist. 


Access Class Banners 


Just as the access class stored in a branch is used internally to 
protect segments, so too wil! the access class banner on aie head 
sheet be used external!y to protect printouts. The access class 
banner provides an administrative controi over the distribution 
of printouts which supersedes the existing discretionary controls 
(i.e. person and project name banners). 


A general rule of the Access Isolation Mechanism dictates that an 
object is assigned an access class equal to the authorization of 
the process that created it. <A strict interpretation of this 
rufe would suggest that the access class assigned to a printout, 
1e-@ey the access class banner. should equal the authorizatlon of 
the ariver process that created ite Unfortunately, this scheme 
would result in widespread over-classification of printouts since 
the ariver process authorization is always at the top of the 
access range of requests handied. Although some sites might be 
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witting to accept thiS Grawback In fhe interest of maximum 
security, if seems iikely that most sites would find it extremely 
objectionable. Since the driver process is realiy Just a trusted 
intermediary which creates ase. orintout on behalf of aiuser 
process, if seems togical, and a great deal more practical, to 
choose the authorization of the requesting user process as the 
access class for a printoute In orcer to satisfy those sltes 
which may prefer the more conservative choice, a new parameter 
will be defined for tne I/0 Daemon parms file which allows = an 
installation to specify a minimum access class banner for each 
device classe If this parameter is not specified, the default 
minimum will be the bottom of the device class access range. 


The new format for a head sheet wiif inciuge a third tine of “big 
letters’ containing the printout access classe Actually, a 
Singte blg-letter tine cannot be expected to hold an arbitrarily 
fong access ciass stringe Therefores only the first component of 
the access ciass string wili be printed in big fetfters. Beneath 
this, the ful! access class will! be printed in reguiar type. 
This implies that at sites using sensitivity ievels, the access 
banner will be a jevel name. At sites using categories but not 
leveiS,s the access banner will be the first category name. 
However, if an access class string is null, as might be desired 
for the system tow access ciass», then no access ciass banner will 
be printed. This impties, of course, that at sites using nelther 
levels nor categories, the access banner will always be omitted. 


Page Lakeis 


The requirement for page header and footer tabels to be added to 
printed output by the I/0 Daemon stems from the neea to place 
access class fabels on each page of certain printouts. However , 
it Is Intended that this feature be generalilzed to aliow a user 
to supply any arbitrary character string for the tlabejs. This 
kind of feature has actualiy been considered before outside the 
context of the Access Isolation Mechanism. The dprint message 
format atready provides space for a page header string, although 
the mechanisa itself has not yet been implemented. 


Several options will be added to the dprint commana to support 
the page iabel feature. If the user simply wishes to use the 
segment access class for the page tabel, he will specity the 
*“eaccess_labei™ optione If the user wishes to supply his oun 
fabel he will specify the “-label™ option followed immediately by 
the fabel string. If neither of these options is specified, then 
no labels willl be addea untess the sife has chosen to aad tiabels 
by default. This will be indicated by a new parameter in the I/0 
Daemon parms flie. The effect of this default labeling will be 
an Implicit “saccess_!abel™ option for ati aprint commands 
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issued. However, a user can override the default label with the 
“elabeil” option or can request no labels by speclfying the 
“eno iabe!™” option. 


Implementation of the tabeling feature would best be accompli lshed 
by providing anew oraer cali to the printer DIM for specifying 
labels. This, in turn, would require modifications to the 
printer OCM which does essentiaily aii of the work for the 
printer DIM. It is intended that the tabels be placed in the top 
and bottom margins of each page so as not to disturb the format 
of the output. Because a number of printer DIM enhancements are 
already in progress», it will most tikely not be practical to 
begin work on the jabel feature in the very near future. 
Therefore, in order to meet the deadline for delivery of this 
feature to AFDSC. an Interim solution may be adopted. A new 
IOSIM can be provided for fhe printer driver process which, when 
spliced in before the printer DIM, wii! insert labels. By use of 
the “noskip™ mode in the printer DIM, ftabels can still be placed 
in the top and bottom page margins as desired. Obvliousty, this 
second approach is tess efficient than the first and therefore 
wili onty be used temporarily if at all. 


Accountability Eorms and Oriver Control Lecminal 


The requirement for accountabliity forms Is primarily to provide 
a means of recording and controtiing the distribution of 
classified output. It also serves a direct security function in 
the separation of output. The distribution staff can check to be 
sure that there is one piece of output (eege, fisting, card deck) 
for each accountablliity form. This check wilil prevent a 
maticious user from imbedaging headers and traiters within his 
data which would fool the distribution staff into believing a 
phoney access class banner. A separate terminal from the current 
daemon console must be used to prepare the accountability forms 
and it should be located near the associated device. 


A byproduct of the accountabdllilty form terminal is its ability to 
- also function as a ariver control terminal. The usefulness of a 
driver contro! terminal stems from physical hardware arrangement. 
Some sites ftocate one or more iine printers (or other 1/0 
devices) in physically separated areas from the central computer. 
However, the daemon driver console must remain in the central 
computer room to prevent privileged access from tailing in the 
hands of untrusted personnel. On the ofher hands the focal 
device operator is In the best position to determine which 
requests should be restarted, etc. Another terminal physically 
focated beside the device could allow the device operator to 
enter benign operational requests without compromising security 
and without requiring assistance from central operations. The 
use of this control/accountability form terminal would, of 
course, be at the option of the site. 
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To impjement this new feature we will add anew per device class 
parameter fo the [0 daemon parms fite which indicates whether a 
contro! terminal is required for the driver. The default for an 
unspecified parameter wil! be “not reaulrad.” When the terminal 
is not required, the driver process willl operate exactiy as it 
does today. 


When a control terminai is required, the ariver wiil waif for a 
terminal to be dlated to the process before teiliing the I/0 
coordinator that it is ready to process requests. However, the 
current impiementatilon of the dial command is too restrictive’ to 
be useful in this context. It only alftows one instance of a 
process_group_id to request dlaied devices. Under the current 
Impiementations drivers and the I0 coordinator are logged in as 
IO0-SysODaemon. Hence, we must implement the changes fo fhe dlal 
command suggested by TeHeVanVieck in MTB 013. 


During normal operation of the driver, the control terminal will 
print one accountabiilty form for each copy of requested oufput 
from the driver process. The form may contain information which 
describes: the requestor, header and destination options, 
sequence number, banner access ciasse date-time, installation, 
pathname and access class of segment. (Notes The module which 
formats the output to the contro! ferminai wll! be site 
repfaceable. The normat mogutie will print the same Information. 
provided by the I/0 Daemon today which does not require a form.) 


A “start” command must be issued from the control! terminal before 
processing witi begin to aliow the device operator to align the 
accountability forms being used. A command to print a sample 
form will be provided for this purpose. Since the output to the 
control! terminal may be formatted to preprinted forms, commands 
may not be entered without destroying the alignment. Therefore, 
commands wilii be honored onty after the device operator presses 
“quit™ on the controt terminate. This allows for realignment 
before resuming operation (we will reset the write buffers). 


The controi terminal will never be allowed to enter arbitrary 
commands for security reasons. AitSoO, we must restrict the set of 
commands, normaily acceptable to the drivers which may be entered 
from this terminal. Specifically, the commands return, debug, 
detach, attach, and reattach will nof be honored from fhe control 
terminal. The ather commands will not create security problems 
{ie@es Start, Cancels kill, restarts saves reinits logout, sample 
(new)). 


We don*t want to remove the site operator®s ability to control 
the driver. Therefore, when the driver expects input, It wlll 
first took for commands from the master driver console ana then 
from the control terminal. (Control! terminal quifs will be 
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disabled while the master terminal has controt of the process). 


The master console wlll also be able to indicate that further 
input and quits from the control terminal be accepted or 
rPratartar . 
¥ wjwwt = Wwe 


If the control terminat gets disconnected, the master console 
will be notified and the driver wilt wait for Instructions. The 
operator may request that the driver continue without the contro! 
terminal or that the driver wait for another dialed terminal 
{(reinit). ; 


A remote driver which communicates to a device over high speed 
Phone tines will atso be able to utillze a contro! terminal. 
This, of course, woulda require a second phone tine. Driver 
commands may be input from the control terminal as described 
above. Commands which may be entered from the remote device 
itself (Cesegey from cara reader) must be subject to the same 
restrictions as commands from the control terminal for security 
reasonse 


Access Control Considerations 


The preceaing sections described changes to the I/0 Daemon to 
support certain new features, This section, however, primarily 
describes changes necessary to cope with the impact of the Access 
Isolation Mechanism on the I/70 Daemon environment. Also» an 
existing security probiem is discussed. 


The I/0 Coordinator, by its very nature, cannot operate sftrictiy 
within the rules of the Access Isolation Mechanism. Since it 
handies information of ail access classes, if will run with a 
system-high access aufhorizatione In order to send wakeups to 
driver processes, it will have the ipc privilege fiag enabted. 
In order to create and modify segments of varying access classes, 
it wll! make use of oprivileged access fo segments and 
directories. In order to read and delete messages of all access 
classes, the coordinator will nave privileged access to message 
segments. 


Several segments exist in lo daemon_dir whlch hold messages and 
message descriptors read by the coordinator from the message 
segment queues. Since these messages willl range in access class 
up to system highs they must be protecteaq in a System high 
segment after extraction from the message segments. Therefore, a 
subdirectory of tLlo vdaemon_dir wlii be created having a 
system-e-high access classe. I[n this alrectory the coordinator will 
create the request_seg (used fo hold messages), the req _desc_seg 
(used to hold message descriptors), and the new walting tist 
segment. 
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Uniike the coordinator, driver processes are, for the most part, 
well-suited to abiding by the restrictions of the Access 
Isofation Mechanism. Therefore, a number of minor changes wiil 
be made fo the I/0 Daemon To avoid the unnecessary use of special 
access privileges. 


The current scheme for initializing driver processes wil! requlre 
slight modifications. Each driver process attempts to verify 
that a coordinator process doeS, in facts exist by ltocklng a 
coordinator lock kept in a speciai segment. If the lock is found 
to be validly locked, then a coordinator existse However, If a 
driver succeeds in locking the tocks then no coordinator exists. 
Unfortunately, tocking the Jock means writing in the segment. 
Since drivers wli! have differing authorizations, they cannot aii 
write in the same segment. Therefore, the drivers will instead 
copy the tock to a private data area and then attempt to flock the 
copye This works even better than The present scheme since It 
eliminates the need for a secondary tock now used to prevent 
interference among drivers. 


The initialization of driver-coordinator communication witi atso 
require some smali' changes. Ali drivers create a temporary 
“communication” segment containing informat lon for the 
coordinator in lo_daemon_dire Due to differing driver 
authorizations, this will no longer be _ possiblie. Therefore, 
these temporary segments wilil instead be created In each driver’s 
process directory. Upon receiving a “new driver” wakeup from a 
driver, the coordinator examines the communication segments 
validates the driver, and then creates a “driver status” segment 
used for future communication. The driver status segment, now 
created in io_daemon_dir, must be writable by the driver process 
and therefore musf have an access class equal to the drivers 
authorizatione Since driver status segments of differing access 
classes Cannot coexist in a single directory, the coordinator 
wilt create a separate upgraded subdirectory in io_daemon_dir to 
hcoia each driver status segment. 


As mentioned above, messages and message descriptors wiil be 
stored in segments of system high access class and hence wil! nof 
be accessibljie to al! driverse Message descriptors are already 
copied to the driver status segment by the coordinator each time 
@ aGriver is given arequeste Currentiy, the driver reags fhe 
message itself directly from the request_seg.e Since this will no 
fjonger be possible, the message will also be copied to the driyer 
status segment by the coordinator at the same time as the message 
descriptor. 


To this polnts every effort has been made to ensure that oariver 
processes would not require the use of any special access 
privileges. Unfortunately, there are two cases in which the use 
of such privileges seems unavoldable. Following each dprint,. a 
driver process executes a program called “charge_user_” which 
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updates accounting information in the pdt entry of the requesting 
user. Since pdt segments have system-low access classes, yet 
driver authorizations may range up to system highs. it will be 
necessary for the drivers to obtain privileged eccess te pdt*s. 
The other circumstance In which specia! access iS required Is 
within the message routing OIM. Alt daemons aftached via the 
message routing DIM must write in a common segment. Therefore, 
mrdim_ wlii be modified to detect the need for special access and 


to attempt to obtain special access. 


A security problem exists due to the fact that fhe coordinator 
process ID and event channet ID are stored in a Segment 
accessible to ali processes. Tnis makes it possible for any 
process to impersonate a driver, is@e,y to drain requests from the 
queues and to issue varlous commands to the coordinator such as 
“restart.” This problem is easily corrected simply by setting 
the ACL of the segment containing the coordinator event channel 
ID to geny access to ail but I[03*.* . 


Detailfea List of Changes 


Ae For Access Ranges 


ie Change Llodc_$init to create the queue group table/walting 
list segment and to store a polnter’§ to this segment In 
lodc static. 


2 Change iodc_parse_parms_ to recognize the new “access_range™ 
and “queue_group” Keywords. Initialize the queue group table 
and thread together device class table entries of the same 
queue groupe Place in each device class table entry the 
offset of the associated queue group table entry. 


3. Change iodc_$new_driver to check if a new driver is the first 
of its device class and if this device class is in turn the 
first of its queue groupe If SO, open the message segments 
in the queue group. 


&. Change find next _requesf_ to use fhe queue group tabie and to 
manage the waiting lists as described. 


5. Change save request. to use the queue group tabie to 
determine from which message segment a given message should 
be deleted. 


Be For Banners? 


1» Change head _sheet_ to print the access class banner. 
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C. 


1. 


2s 


Se 


4e 


5. 


66 


36 


Le 


For Page Labetss’ 


Change the dprint command to recognize the new -access_label, 
label. and -no_label options. 


Change ioac_parse_parms_ to recognize the new “label" 
parameter which causes tabeis to be added to printouts by 
default. 


Change outpuf_requesf_ to check for the fabel option and to 
make the appropriate order calli if it is requested. 


Change prinfer_aim_ to recognize a new “fabel” order call and 
to pass this on to the printer DCM. 


Change printer_ccm_ to recognize the jiabei order cati and to 
Insert labels in the top and bottom page margins. 


If changes 4& and 5 cannot be made soon enough to meet. the 


delivery deadline, then impiement a new IOSIM to add labels 
as described. 
For Accountabillty Form/Device Control Terminals 


Change iodc_parse_parms_ to recognize the “control_terminai”™ 
keyword. 


Change iodd_ static to hold control terminal attachment data. 


Change remote_Sinit ana io_daemon_adriver_ to attach. confrol 
terminal if required. 


Change iodd_quit handier to conditionally recognize input 
from control terminal and implement sample command. 


Change Input _cmd_ and remote_ to separate commands’ from 
master and contro! terminal. 


Change oufput_request to call accountability form printing 
module if a contro! terminal Is attached. 


Change the answering service dial facility per MTB G13. 


For Access Contro! Considerations? 


Change iodc_init to enable the necessary special access 
privifeges for the coordinator. Create a system high 
directory in which to place requesf seg, req_idesc_seg, and 
The queue group table segment. 
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Change lod_overseer_ to copy the coordinator tock before 
testing it for a driver process. 


Cnange driver_init Ssignai fo creates the driver_comm segment 
in the process directory and to store the process 
authorization In the driver_comm structure. 


Change iodc_$S$nen_driver to create an upgraded directory and 
hoid each driver status segment. 


Change iode_$driver_signal to copy each dprint message to the 
driver status segment. 


Change charge_user_ and ardin_ to use privileged segment 
access as described. 


